home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940227.txt < prev    next >
Internet Message Format  |  1994-11-13  |  20KB

  1. Date: Mon, 11 Jul 94 04:30:17 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #227
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Mon, 11 Jul 94       Volume 94 : Issue  227
  11.  
  12. Today's Topics:
  13.                              44.x subnets
  14.                  How is WEFAX encoded for grey scale?
  15.                        National Traffic System
  16.                      New IP Address when Moving?
  17.                   PPP to Internet Over Packet Radio
  18.       tncdr106.zip - TNCDOOR: Run Ham Packet Radio from BBS door
  19.                      Troubleshooting Tips Needed
  20.  
  21. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  22. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  23. Problems you can't solve otherwise to brian@ucsd.edu.
  24.  
  25. Archives of past issues of the Ham-Digital Digest are available 
  26. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  27.  
  28. We trust that readers are intelligent enough to realize that all text
  29. herein consists of personal comments and does not represent the official
  30. policies or positions of any party.  Your mileage may vary.  So there.
  31. ----------------------------------------------------------------------
  32.  
  33. Date: Mon, 11 Jul 1994 05:59:46 GMT
  34. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!news.sibylline.com!eskimo!rdonnell@network.ucsd.edu
  35. Subject: 44.x subnets
  36. To: ham-digital@ucsd.edu
  37.  
  38. William Vaughn (vaughnwt@olympus.net) wrote:
  39.  
  40. : >As I see it, since the 44 network is subdivided (2nd octet) by US state or
  41. : David, What is a 44 network? Where do I get some info? Thanks.
  42. : William Vaughn    vaughnwt@olympus.net "Just plain Bill."
  43.  
  44. The '44 network' refers to the IP address space that is allocated to the
  45. 'ampr.org' domain, that one used by amateurs.  In other words, internet
  46. protocol addresses of the form '44.x.x.x' where x is a number from 0 to 255,
  47. with certain reservations.  
  48.  
  49. There are national and regional IP address coordinators for the 44 network. 
  50.  
  51. If you're a ham and interested in using TCP/IP networking over amateur
  52. radio, let me know where you are located, and I'll try to locate the
  53. coordinator for your area and pass the info back to you.
  54.  
  55.  
  56. 73, 
  57.  
  58. Bob, KD7NM (Amateur Radio IP address coordinator for Western Washington)
  59. --
  60. ---------------------------------------------------------------------------
  61. Bob Donnell, kd7nm     bob@ethanac.kd7nm.ampr.org   rdonnell@eskimo.com
  62. ---------------------------------------------------------------------------
  63.  
  64. ------------------------------
  65.  
  66. Date: Mon, 11 Jul 1994 00:37:04 GMT
  67. From: world!eac@uunet.uu.net
  68. Subject: How is WEFAX encoded for grey scale?
  69. To: ham-digital@ucsd.edu
  70.  
  71. In <hamilton.773788184@BIX.com> hamilton@BIX.com (hamilton on BIX) writes:
  72.  
  73.  
  74. >What is the actual WEFAX encoding mechanism?  Is it analog or digital?
  75.  
  76. WEFAX is analog. The HF (or FM) system uses the frequency of the signal to
  77. determine the greyscale.  The Weather Satellite (or AM) system uses the
  78. amplitude of a 2400 Hz tone.  Sync is at the start by using a signal that
  79. alternates between black and white.  The chart takes from three to ten
  80. minutes to transmit, so frequency stability and accuracy of the sampling
  81. clock has to be good.  No sync in the HF system during the chart, but I
  82. think there is a bar in the Satellite system because there is no start or
  83. end.
  84.  
  85. SSTV (at least the old 8 second B&W) is similar in that the same frequencies
  86. are used for the video information (1500 to 2300). Just consider Wefax to
  87. be a very slow Hi-Res SSTV signal without the 1200 Hz sync pulses.
  88.  
  89. 73 Eric... WB1HBU eac@world.std.com
  90.  
  91. ------------------------------
  92.  
  93. Date: Sun, 10 Jul 94 10:51:37 PDT
  94. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!gatech!udel!news.sprintlink.net!crash!bssbbs!tmill493@network.ucsd.edu
  95. Subject: National Traffic System
  96. To: ham-digital@ucsd.edu
  97.  
  98. I posted a message here a couple days back concerning the importance of
  99. the National Traffic System, and unfortunately my keyboard is sticking
  100. from time to time, and making a few mistakes. Of course I could never
  101. make any mistakes, or.....could I?  So here goes my message once
  102. again, hopefully without the "typos".
  103.  
  104.  
  105. Good day ladies and gentlemen. I would like to bring up a subject very
  106. important to ham radio. At least I think it is. That being the National
  107. Traffic System. For those of you who do not know what the National Traffic
  108. System is, it is basically a network in which 3rd party messages can
  109. passed for hams and non-hams alike. In fact, the system needs your help!
  110. When was the last time you checked into a voice traffic net? In fact, by
  111. reading this, you are telling me that you are interested in
  112. digital communications, and may be involved in packet. You too can help
  113. in this very valuable service. The next time you check into a
  114. "fullservice" bbs, type "LT", and hit your enter key. If there are any
  115. traffic messages they will be listed out for you. Are there any messages
  116. in your local calling area listed? If there is, why not print them
  117. out, pick up your phone and deliver the message to the person so named.
  118. After you have copied the message "kill it", so no one else
  119. will duplicate your efforts. You might offer to send a message back for
  120. them. That is great PR for ham radio!! If you ever have any
  121. questions, drop me a note. I will try and answer any questions I can.
  122. This form of traffic handling can be great practice for when we really
  123. need it. In times of emergencies, such as earthquakes, hurricanes, tornadoes,
  124. fires, and well, I think you get the picture. Until next time, 73,
  125. Tuck, KC6ZEC
  126.  
  127. /s
  128.  
  129. ------------------------------
  130.  
  131. Date: Mon, 11 Jul 1994 05:14:36 GMT
  132. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!news.sibylline.com!eskimo!rdonnell@network.ucsd.edu
  133. Subject: New IP Address when Moving?
  134. To: ham-digital@ucsd.edu
  135.  
  136. Shannon Miller (smiller@intelsun.rus.uni-stuttgart.de) wrote:
  137. : Here's a question for which I can't seem to get a straight answer:
  138.  
  139. : I got a TCP/IP address allocated to me when I lived in Oregon and
  140. : operated as N7APC.  Now I live in Germany and operate as DL6SEU.
  141. : To get on the air with TCP/IP quickly I simply made use of my old
  142. : IP address.  The question:  -should- I get a "local" (German) IP
  143. : address?  In any event I want to keep my original IP address as I
  144. : plan to return to the U.S. someday.
  145.  
  146. : My Oregon IP address works fine of course, and shouldn't be in use
  147. : by any other station on the planet (since N7APC is off the air as
  148. : long as I'm here!), but one can easily tell that I'm not in the
  149. : same "subnetwork" as the locals.
  150.  
  151. Hi Shannon,
  152.  
  153. If you'd moved a couple of hundered miles north, to Western Washington,
  154. you'd definitly need a new address.  In this area we are using subnetting
  155. for all routing, so addresses are issued on an lan-by-lan basis.  Currently
  156. we use a 24-bit mask, so each subnet has 254 possible users.  This is
  157. definitly more than any one lan can support simultaniously, but allows us to
  158. use RIP effectivly.  Also makes a bit more work for yours truely as the
  159. address coordinator for this area.  A bit of dBase programming has eased the
  160. process considerably tho.  
  161.  
  162. The biggest problem we seem to have with the whole subnetting process is
  163. shrinking / breaking up lans that have developed hidden transmitters.
  164.  
  165. Be aware too that there are a number of gateways to internet, and if your
  166. local lan gets this kind of access, you really can't use just any old IP
  167. address, if you want to make use of any of the routers, etc.  They'll send
  168. acks to your connect packets back to the entry in their routing table, and
  169. that probably won't be to your station.
  170.  
  171. Also, if you have more than one IP address associated with a particular host
  172. name, and all addresses are not active (on the air) at the same time, a
  173. domain lookup to that host name may result in a connect attempt to the
  174. inactive address, so a different host name is generally necessary for each
  175. lan you are on if you are not on all of them at the same time.
  176.  
  177. : Many thanks,
  178.  
  179. : --Shannon, DL6SEU/N7APC
  180.  
  181.  
  182. Sure thing!  73
  183. --
  184. ---------------------------------------------------------------------------
  185. Bob Donnell, kd7nm     bob@ethanac.kd7nm.ampr.org   rdonnell@eskimo.com
  186. ---------------------------------------------------------------------------
  187.  
  188. ------------------------------
  189.  
  190. Date: Mon, 11 Jul 1994 05:34:56 GMT
  191. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!news.sibylline.com!eskimo!rdonnell@network.ucsd.edu
  192. Subject: PPP to Internet Over Packet Radio
  193. To: ham-digital@ucsd.edu
  194.  
  195. David Greeson (dgreeson@newbridge.com) wrote:
  196.  
  197. : I was interested in the speed of packet radio (i.e. bits/second) and
  198. : whether anybody was using it to hook into the Internet using a protocol
  199. : like SLIP or PPP (Linux PC).  A college friend of mine had a packet radio
  200. : setup and it seemed like a very neat idea, but the data rate was slow.
  201. : That was 10 years ago where everything was slow as compared to today's
  202. : modems.  Any improvements?
  203.  
  204.  
  205. Most amateur packet activity (99%)is still at 1200 bauds, definitly not a
  206. speed demon.  In some areas there is 9600 and 19200 baud activity, which
  207. isn't bad, and in probably 3-4 areas there are lans running at 56 k or
  208. faster.
  209.  
  210. With AX25 drivers or the amateur TCP/IP packages, PPP over the air is not
  211. necessary.  Each station has an assigned IP address, either by a
  212. coordinator (I'm one) or from a block assigned to a bootp server.  The
  213. latter is not common yet.  At this time some areas have gateways to
  214. internet, with varying restrictions depending on abuse and operator
  215. sensitivity as to what is acceptable to allow to enter their amateur network
  216. from the internet.  Unfortunatly the FCC has something to say about content
  217. of information transfered via amateur radio, and each gateway operator has
  218. to come to a decision as to how far out on a thread he wants to hang his
  219. amateur license.
  220.  
  221. With a reliable internet gateway connection, mail and ftp are possible, but
  222. tend to suffer because the slow speed and relativly high error/loss rate
  223. with radio circuits are not compatible with the expectations of the typical
  224. computer on the internet, especially retry and timeout timer adjustments. 
  225. Unless you are in one of the areas where higher speed operations ( greater
  226. than 9600/19200) are done, things like Mosiac are not feasable, and the
  227. hardware for the higher speeds is not yet available in a plug-and-play form,
  228. in fact, it's a loooonnng way from that yet for any speed except perhaps
  229. 1200 baud in some circumstances.  Still a lot of room for improvement!
  230.  
  231. Hope that gives a small idea of where amateur packet radio is, compared to
  232. typical internet access.
  233.  
  234. : David Greeson : dgreeson@newbridge.com
  235.  
  236.  
  237. --
  238. ---------------------------------------------------------------------------
  239. Bob Donnell, kd7nm     bob@ethanac.kd7nm.ampr.org   rdonnell@eskimo.com
  240. ---------------------------------------------------------------------------
  241.  
  242. ------------------------------
  243.  
  244. Date: 11 Jul 1994 04:21:30 GMT
  245. From: juniper.almaden.ibm.com!enge.almaden.ibm.com!enge@uunet.uu.net
  246. Subject: tncdr106.zip - TNCDOOR: Run Ham Packet Radio from BBS door
  247. To: ham-digital@ucsd.edu
  248.  
  249. Note that the rules would also require that the user possess a license
  250. or that the SYSOP be in attendance and monitor the transmissions.
  251.  
  252. Roy, AA4RE
  253. enge@almaden.ibm.com
  254.  
  255. ------------------------------
  256.  
  257. Date: Mon, 11 Jul 1994 05:51:09 GMT
  258. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!news.sibylline.com!eskimo!rdonnell@network.ucsd.edu
  259. Subject: Troubleshooting Tips Needed
  260. To: ham-digital@ucsd.edu
  261.  
  262. James Meade (jnmeade@blue.weeg.uiowa.edu) wrote:
  263. : I'm trying to get some equipment together and am getting pretty
  264. : frustrated.  I need some help in good troubleshooting techniques, or
  265. : tips on what I mgiht be overlooking.
  266.  
  267.  
  268. As a former customer service rep for one of the TNC makers, the most common
  269. setup problem of a beginner I observed was that the transmit audio level
  270. from the modem to the radio was set incorrectly.  The best way to set this
  271. is with a deviation meter.  Make sure the radio's deviation limiter is set
  272. to limit deviation at 5 kHz, then adjust the output level of the modem to
  273. drive the radio to 2.5-3.5 kHz of deviation.  The high tone (2200 Hz) should
  274. be set to 3.5 kHz, and with the normal pre-emphasis in the radio, this will
  275. usually result in the low tone (1200 Hz) deviating the radio about 2.5 kHz. 
  276. When in doubt, use a lower level rather than a higher level - most modems
  277. have trouble with distorted audio.
  278.  
  279.  
  280. If you have to set the TX level without a deviation meter, monitor your
  281. signal with another receiver (scanner, HT, or whatever) and if possible use
  282. a scope to look at the receiver's audio.  Note how loud other stations on
  283. the channel are, and set yours a little lower - as I said, the most common
  284. setup error is too much TX audio.
  285.  
  286. Hope that helps.
  287.  
  288. : Jim - Farmer - Iowa City, IA, 
  289.  
  290. Bob, KD7NM - near Seattle, WA
  291.  
  292. --
  293. ---------------------------------------------------------------------------
  294. Bob Donnell, kd7nm     bob@ethanac.kd7nm.ampr.org   rdonnell@eskimo.com
  295. ---------------------------------------------------------------------------
  296.  
  297. ------------------------------
  298.  
  299. Date: 10 Jul 1994 17:24:11 GMT
  300. From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!vixen.cso.uiuc.edu!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen!drenze@network.ucsd.edu
  301. To: ham-digital@ucsd.edu
  302.  
  303. References <gTP6oc1w165w@bssbbs.com>, <eJn7kexGLXs0067yn@cris.com>, <2vnt9m$9va@network.ucsd.edu>ws
  304. Subject : Re: NTS traffic
  305.  
  306. brian@nothing.ucsd.edu (Brian Kantor) writes:
  307.  
  308. >The NTS is an obsolete system for transferring small bits of information
  309. >in an inefficient way.  It is primarily of interest to old-time hams.
  310. >When the best method of communication was hand-sent Morse, the NTS had
  311. >a reason to exist.  It no longer does.
  312.  
  313. >In today's environment of cellular telephones, trunked radio systems
  314. >with data screens, and nearly universal deployment of FAX machines,
  315. >the NTS people could best serve their community by staying out of the
  316. >way of real emergency personnel doing their jobs.
  317.  
  318. Not true, Brian!  Unfortunately, many of these systems are extremely
  319. limited in ways that hurt more than the limitations of NTS.  To begin
  320. with, there are only a limited number of cellular communications channels
  321. available in any given locale.  While this number is very high, just
  322. remember that many, *many* people have access to cellular
  323. communications...which are going to turn into primary forms of
  324. communications when the regular phone circuits go out.  I believe it was
  325. in the last large Cali quake that this limitation was truly noticed.  The
  326. media saturated the area.  Unfortunately, each and every member of the
  327. media had a cellfone and a deadline to make.  As I recall, the cellular
  328. circuits still in service were so saturated that vital emergency traffic
  329. simply could *not* get through!
  330.     Another problem with the use of cellular communications and FAX
  331. machines is what to do when the power goes down.  Unfortunately, many of
  332. these deployed devices run off of line AC with no provisions for battery
  333. backup.  Hrm.  You lose a large part of the power grid of a major
  334. metropolitan city and you lose a large part of your communications
  335. network.
  336.     Yet another problem with the use of trunked radio systems, etc. is
  337. that if civil defense agencies had to own, maintain, and train operators
  338. for much of the equipment amateur radio operators bring to the scene, then
  339. they'd have to have the funding for them...which would come out of the
  340. taxpayers' pockets.  You'd hear screaming then!
  341.     Contrast this to Amateur Radio.  We bring our own equipment to the
  342. scene.  The people who volunteer for this have generally been trained by
  343. ARES or MARS or whomever to respond to such things.  We generally stay at
  344. specific CCC centers to pass messages, leaving the people who have
  345. actually been trained to deal with the emergency to do what they do
  346. best...deal with it!  While I agree that Joe Ham should stay the heck out
  347. of the way, ARES, MARS, and other emergency response groups provide a
  348. valuable service, just ask anybody who has worked with them.
  349.     There does need to be something of a paradigm shift about how
  350. messages are passed, though.  Hammering them out in CW doesn't make much
  351. sense when you can pass them faster using SSB or packet.  Passing them all
  352. the way around the country makes little sense when you can pass them to a
  353. communications post outside the emergency zone, then get them on to faster
  354. means of communication, such as the telephone, Internet, teletype, FAX, or
  355. whatever.  Rather than eliminating the NTS, it ought to be integrated more
  356. fully into the grand scheme of things.
  357.     And to whomever was complaining about getting NTS messages
  358. returned because of length, why would you send a novel via NTS anyway? 
  359. I've never come across a message I've wanted to send via NTS that couldn't
  360. be expressed in a dozen words or less--usually with one of the ARRL stock
  361. messages.
  362.  
  363. -- 
  364. ---
  365.          Doug Renze, N0YVW * drenze@isca.uiowa.edu * N0YVW @ W0IUQ.ia.usa.na
  366.                                 DRenze@aol.com
  367.  
  368. ------------------------------
  369.  
  370. Date: Sun, 10 Jul 94 07:07:13 -0800
  371. From: amd!amdahl!grafex.sbay.org!ka6etb@decwrl.dec.com
  372. To: ham-digital@ucsd.edu
  373.  
  374. References <eJn7kexGLXs0067yn@cris.com>, <gTP6oc1w165w@bssbbs.com>, <2vnt9m$9va@network.ucsd.edu>.o
  375. Reply-To : ka6etb@grafex.sbay.org
  376. Subject : Re: NTS traffic
  377.  
  378. In <2vnt9m$9va@network.ucsd.edu> brian@nothing.ucsd.edu (Brian Kantor) writes:
  379. >The NTS is an obsolete system for transferring small bits of information
  380. >in an inefficient way.  It is primarily of interest to old-time hams.
  381. >When the best method of communication was hand-sent Morse, the NTS had
  382. >a reason to exist.  It no longer does.
  383.  
  384. Most emergency traffic is is small bits of information.
  385.  
  386. Far more NTS traffic was handled via the PBBS system than via Morse or
  387. voice during the Loma Prieta earthquake...by an order of better than
  388. 10 to 1.
  389.  
  390. >In today's environment of cellular telephones, trunked radio systems
  391. >with data screens, and nearly universal deployment of FAX machines,
  392. >the NTS people could best serve their community by staying out of the
  393. >way of real emergency personnel doing their jobs.
  394.  
  395. Here in Santa Clara County, officials rely on amateur radio communications,
  396. primarily RACES and ARES.  Perhaps, as you say, there are other "more
  397. better" ways of communication, but there is a cost factor.  And, it
  398. has nothing to do with NTS.
  399.  
  400. During the earthquake, cell phone in the affected area was down, as I
  401. recall.  Those things don't work too so terribly good when they are
  402. broken.  Here in our area, any ham with a hand-held can hit a repeater.
  403. Not true, in most areas, I admit.
  404.  
  405. Where NTS excelled during the earthquake, was the handling of Health &
  406. Welfare traffic.  For quite a period (2 or 3 days, as I recall), there
  407. was no inbound telephone calls allowed.  Those folks whose phones worked
  408. could call out if they could get an open line.  Didn't matter if it
  409. was a cell phone or not.
  410.  
  411. I mentioned in an earlier post that I live three miles from the epicenter
  412. of the Loma Prieta quake.  We were fortunate in that our power was only
  413. off for a few hours, and our telly line never broke.  Folks a mile away
  414. were without power for days and telly service was intermittent at best.
  415.  
  416. I was busy for a couple of days handling NTS H&W traffic.
  417.  
  418. This thread is beginning to stray from digital.misc.
  419.  
  420. s
  421.  
  422. ------------------------------
  423.  
  424. End of Ham-Digital Digest V94 #227
  425. ******************************
  426.